Software handling of hardware errors

ABSTRACT

A system and method that detects hardware and software errors in an embedded system that includes detecting or measuring an operating state; causing one or more computation engines to operates in group synchrony; causing one or more active monitors that monitor the computation engines to an automotive integrity level to operate in group synchrony; synchronizing the communication between and from the plurality of computation engines and the plurality of active monitors, respectively; and arbitrating the output generated by the computation engines and the active monitors.

BACKGROUND OF THE DISCLOSURE 1. Technical Field

This disclosure relates to embedded software systems and specifically todistributed architectures that render tunable immunity to software andhardware faults.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure can be better understood with reference to the followingdrawings and description. The components in the figures are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the disclosure. Moreover, in the figures, likereferenced numerals designate corresponding parts throughout thedifferent views.

FIG. 1 is a logical view of an embedded system.

FIG. 2 is a virtual synchrony extension of an embedded system.

FIG. 3 is a virtual synchrony extension of an embedded system withactive monitors and arbitrators.

FIG. 4 is an implementation of a virtual synchrony extension of anembedded system with active monitors and arbitrators.

FIG. 5 is a second virtual synchrony extension of an embedded systemwith active monitors and arbitrators.

FIG. 6 is a flow diagram of a virtual synchrony extension of an embeddedsystem with active monitors and arbitrators.

DETAILED DESCRIPTION

Hardware such as processors and memory are becoming significantly lessreliable. As hardware gets smaller, it is failing more frequently. Itsreduced size and increasing complexity makes it susceptible to thesecondary effects of cosmic rays, internal cross-talk, andelectromagnetic interference that can cause transient or soft errors.The random and transient nature of these soft errors make the errorsdifficult to detect and trace to their source. The errors can be maskedand may propagate through other operations before even being detected.

To make matters worse, the underlying hardware that executes many of theapplication programs includes caches and coprocessors, for example, andthese are hidden from the operating systems and application programs.So, when errors occur, such as when a bit flips randomly within memory,the error goes undetected until the application program completes anoperation.

Improved error detection at the hardware level has been ineffective inaddressing this problem. The hardware is often expensive and notfit-for-purpose. In other words, the hardware's processing is notnecessarily appropriate and compliant with the necessary standard forits intended use.

This disclosure provides a loosely-coupled locked-step architecture forembedded systems. Embedded systems are those systems that are made anintegral part of another system or process, such as a vehicle or medicaldevice, for example. The architecture makes use of replication anddiversification through virtual synchrony to provide resilience againstrandom or non-reproducible hardware errors that can give rise todifferent failures that can occur much later in a processing thread thanwhen the original fault first occurs. The architecture is effective indetecting and mediating software errors too, such as heisenbugs, forexample that are becoming more common as more multi-thread code runs onmulti-core processors. Unlike software bugs that have properties that donot change when debugging code is inserted into source or object code,heisenbugs are a type of will-of-the-wisp error that arbitrarily appearand disappear in a manner that makes them elusive. Heisenbugs can becaused by subtle timing problems, for example, such as when a threadrunning on one processor core releases a buffer that is subsequentlywritten to by another thread. In some instances, heisenbugs can giverise to different arbitrary faults at earlier and later times of theprocessing operation. The fault's unpredictability and randomness causessome to refer to heisenbugs as non-reproducible bugs.

When a software instance fails, for example, because of a random error,the disclosed architecture ensures that the failing system continues tooperate. In some instances, the failing system may operate in a degradedstate. When detected, the architecture's middleware may automaticallyisolate the failure and reboot or restart the failing hardware or rebootor restart all or a portion of the system's code such as that portionthat is failing. This resilience provides a level of “fail-operational”behavior.

When a severe failure occurs or the system completely fails, the systemmay move to a design-safe-state (DSS). A DSS is a device or process,that in the event of a specific type of event, responds or results in acertain way such as in a way that reduces or avoids harm to the deviceor user. In other words, it is a state that the system enters when thesystem doesn't know what else to do. A specific type of event mayinclude: an event which the system was not programmed to handle, anevent it would fail to respond to in a timely manner, an event that itwould respond to correctly, but if it did, it would corrupt its owninternal state in such a way future events might not be handledcorrectly, for example. The DSS is programmed during the system's designor application and may vary with environments and events. It may occur,for example, when a drug dispensing system fails—in that case, it maystop the drug flow, in a vehicle application it may apply the brakes orrelinquish autonomous control (i.e., hand control to human driver of aself-driving vehicle).

The disclosed architecture separates two aspects of software design: (1)the technical and algorithmic skill required to write or implementsoftware that fulfills a particular purpose; and (2) the statisticalskill required to determine the level and timing of replication anddiversity. The disclosed architecture allows the level of resiliencyrequired for a particular subsystem to be programmed during thesoftware's development and to be tuned dynamically before or during itsoperation in its intended operating environment or state. In a vehicleapplication the operating environment or state may comprise a cruisingstate, an urban driving state, a rural driving state, a parking state, ahigh or a low traffic congestion state, or any other vehicle operatingstate or any traffic condition state or any combination of any of theabove environments or states. And, the resiliency level establishes thenumber of replicas and their activation times or periods, the number ofresponses required before a response is accepted and acted upon, and thenumber of diverse implementations required.

The disclosed architecture also supports diverse computation engines andactive monitors or safety bags which enables design to be partitionedin-line with the automotive safety integrity levels (ASILs) includingthe decomposition levels called out in the ISO 26262 standard, forexample. The ISO 26262 standard is the specialization of functionalsafety standard of electrical/electronic/programmable electronic safetyrelated systems of the IEC 61508 standard for production cars.References to the ISO 26262 and other standards that follow include thecurrent and future versions of those standards, any related standards tothe current and future versions, and any superseding standards.

The underlying replication and diversification of the disclosedarchitecture can verify new and legacy software efficiently at the startor during software execution to the functional safety levels of astandard such as the automotive safety integrity levels ASIL A, B, C, orD described in the ISO 26262 standard without building compliantsoftware from the start. The disclosed architecture and middleware mayreduce the evidence a software program requires for certification bycertification authorities and ensures operational integrity levels, thatin some instance, can be associated with a measure or a level ofestablished safety.

FIG. 1 is a logical view of a system that is made integral to anothersystem (e.g., it is embedded) such as a vehicle (not shown). The systemincludes a computation engine 102 interfaced to and in communicationwith a plurality of sensors 104 and actuators 106. The sensors 104 caninclude automotive sensors such as one or more or a combination thatdetect or measure engine functions, vehicle operating functions,entertainment and climate functions, and chassis functions, for example,that may convert nonelectrical energy into electrical energy. Thesensors 104 may measure distance driven, vehicle speed, safety equipmentin-use, acceleration, braking (or deceleration), traffic conditions(high congestion vs. low congestion), road conditions, throttleposition, engine coolant temperature, manifold absolute pressure, oxygencontent, entertainment and climate status, airbag status, anti-lockbraking, relative distance to other objects, wheel spin, closing speedon a vehicle's front, rear, and sides, tire pressure, driveridentification, camera images, surveying technology such as Lidar,keyboards, etc. The computation engine 102 processes the sensors' outputor a combined output of multiple sensors (shown as sensor fusion 108)through a processor and an application program that comprises thecomputation engine 102. In response to a control signal transmitted fromthe computation engine 102 or through another computation engine, theactuators 106 shown in FIG. 1 activate, control, or put into motionanother mechanism or system (shown as hardware 110) such as a mechanicaldevice. The mechanism or system may release a vehicle's brakes, forexample, or cause a self-driving vehicle to turn a corner or approach adestination, etc.

When a higher level of availability or reliability is required, thecomputation engine shown in FIG. 1 may be replicated and diversified.The term availability generally refers to how often an embeddedcomponent responds; and the term reliability generally refers to howoften that response is correct. In other words, the computation enginemay be replicated and the outputs compared to ensure consistency,accuracy, reliability, accessibility, and immunity to faults. An activereplication may be implemented through software provided the replicasare synchronized. Synchronization may require protocols to ensure thatthe replicas remain in step. A benefit of the disclosed loosely-coupledlocked-step architecture is its middleware 204 that virtually sitsbetween the computation engine instances or replicas 202 and the sensors104 and actuators 110 and synchronizes them without changing theseprograms as shown in FIG. 2.

The underlying form of replication or diversification implemented in theloosely-coupled locked-step architecture is that, if each computationengine begins in the same state and each receives the same data andmessages in the same order, then all of the computation engines willarrive (eventually) at the same state and give the appearance of asynchronous execution (e.g., group synchrony). This means, any number ofcomputation engines 202 will process messages and data in groupmemberships through an ordered and concurrent message delivery inresponse to a reliable message delivery received through the middleware204 across a bus. In an embedded environment, such as a vehicle, forexample, data volume is relatively small and the operations performed onthat data are complex when compared to the synchronization that canoccur on a server farm. In vehicles, messages are often transmittedacross a local serial bus, Ethernet, or controller area network (CAN)rather than an openly accessible distributed network like the Internetthat a server farm uses. And, the calculations performed by computationengines in the vehicle may be complex requiring it to determine whethera target in an image captured by a front-facing camera, for example, isa person or a shadow, or the calculations may decide when to apply thevehicle's brakes and at what pressure, versus the less complex operationof merely providing high throughput via a server farm.

In FIG. 2 the communication framework of the loosely-coupled locked-steparchitecture joins group or replicated computation engines 202 into agroup membership. A particular computation engine may join severalgroups and a group may contain any number of computation engines. Themembers of a group may be physically distinct and executed on differentprocessors, and to avoid single points of failure, the architectureoperates without access to a common or global clock. Timing occursthrough an ordering of events such as through Lamport techniques andrelationships that ensure every group member receives every event in thesame order.

In FIG. 2 each group member starts in the same digital logic state andprocesses the same events in the same order. All members reach the samesynchronization points, albeit it can be at different times. Thisoperating behavior is not a hard synchronization of the computationengines as would result from a hardware locked-step, rather it is aloosely-coupled locked-step where each step is the completion of theprocessing of a particular event by the slowest computational enginemember of the group.

Other, looser, event orderings are practiced when different members of agroup are allowed to receive messages in different orders. When a strictsequence is not necessary, an additional level of entropy is introducedinto the embedded system, increasing resilience against heisenbugs thatmight be associated with the precise sequencing of messages.

As in FIG. 1, the sensors 104 shown in FIG. 2 provide data to the groupof replicated and diversified computation engines 202 that present theappearance of and respond like a single computational engine to thedevices it communicates with. The data it processes, however, areintercepted by the middleware 204 and presented to each engine instanceaccording to a defined order. In one implementation, each computationalengine is unaware of its other group members and performs its own(complex) calculations. When the actuators 106 query the group of thereplicated or diversified computation engines 202, depending on thedependability level required, the actuators 106 can request a responsebased on one, two, or more, or all the instances of the replicated anddiversified computation engines group members 202. Unless all responsesare requested, the middleware 204 discards the unwanted responses,thereby improving the architecture's performance.

The number of responses requested by an actuator 106 that a response isbased on allows the actuator 106 to balance the importance ofavailability relative to reliability. The measure of importance betweenhow many computation engines instances respond versus how often acomputation engine instance's response is correct changes dynamically insome architectures depending on the current systems operatingenvironment and event. For example, when a vehicle is travelling at highrate of speed on a highway, availability is likely to be more of apriority than reliability. Likewise, when the vehicle is travellingslowly in an urban environment, reliability might take precedence overavailability. The actuator makes the choice of how to respond given theresponses it received.

The system illustrated in FIG. 2 illustrates a single layer of sensors104 and actuators 106 requesting services (e.g., acting as clients) andcomputation engines 202 that communicate with the sensors 104 andtransmit commands to the actuators 106 (e.g., acting as servers). Inalternative implementations the computation engines 202 also act asclients to other groups or instances of computation engines. Because ofthe isolation provided by the distributed nature of the loosely-coupledlocked-step architecture, this alternative implementation does not alterthe implementation of the computation engines.

In some systems compliant with the ISO 26262 standard or the IEC 61508standard, safety bags or active monitors 304 join the group ofreplicated or diversified computation engines 306 and may operateseparately in group synchrony as shown in FIG. 3. In thisimplementation, the algorithm executed by the computation engines 306 isabstracted to define the optimal response of the computational engines306 under the system's operating condition which is then processed byone or more active monitor instances to assure that the computationengines operate at an expected quality level. A difference between thecomputational engine instances 306 and the active monitor instances 304is that the active monitor instances 304 have a lower level ofcomplexity. For example, in a vehicle cruise control application, thecomputational engines may accept speed and distance data from internaland road-side sensors, taking into account the gradient and elevation ofthe road and the densities of surrounding traffic to determine anoptimal point to disengage the vehicle cruise control application. Someimplementations of the active monitor instances 304, on the other hand,may receive some or all of the same information but base calculationsonly on predetermined movement limits and internal sensor data. Theactive monitors execute a less complex algorithm to determine an optimalrange to disengage the vehicle cruise control application.

Although less complex, and in some instances generating a sub-optimaloutput when compared to the output of the computational engines, theactive monitors 304 assure the overall embedded system is operating atan integrity level (or a vehicle integrity level). The assurance comesfrom the active monitors 304 identifying composite limits or ranges thatare compared to the composite output of the computation engine instances306 by the middleware 204. The middleware 204 appropriately flags anydifferences or discrepancies before both outputs and associated flagsare transmitted directly to one or more of the actuators 106 or anintermediate arbiter (not shown) that transmits control signals to oneor more of the actuators 106. In FIGS. 3 and 5, the shaded portions 302of the actuators 106 represent the arbitration logic or arbiter devicesused by the actuators 106 to determine how the actuators 106 respond. Inone version, the arbiters command and one or more of the actuators 106apply a DSS when a severe conflict or severe reliability issue arises.In another version, the arbiter modifies or alters the output of thecomputational engines shown as QM instances 306 so that it is compliantwith the monitoring standard before it is transmitted to the actuators.

FIG. 3 shows how the architecture shown in FIG. 2 can be reconfigured tosupport safety bags or active monitors 304 operating to a virtualsynchrony model. The computation engine instances or replicas designatedquality management (QM) 306 indicate that the computation enginesinstances 306 were developed under a quality management system asdefined in the ISO 26262 standard, but have not been certified to anautomotive safety integrity levels such as ASIL A, B, C, or D of the ISO26262 standard. The active monitor instances 304 designated automotivesafety integrity level-C (ASIL-C) in FIG. 3, establish that thereplicated monitor instances are monitoring and tracking the outputs ofthe QM instances to the automotive safety integrity level C. Under theISO 26262 standard, QM imposes the fewest development requirements, andASIL-D the most development requirements, and ASIL-C is an intermediatedevelopment requirement that falls between ASIL-A and ASIL-D.

In FIGS. 3 and 5, diverse instances of the computation engines 306 canbe members of the same group. Because of their complexity, thesecomputation engines instances 306 may not be or cannot be certified toan ASIL standard. The decomposition provided by the safety bags oractive monitors 304 shown in FIGS. 3 and 5 allow the entire embeddedsystem to be certified. In other implementations, the middleware 204itself is certified. As shown, the purpose(s) that the embedded systemsare to fulfill is executed by the QM devices 306 or processes that aremonitored by the ASIL-C devices or processes.

The comparison of the various responses from the QM group members 306 orbetween the membership and the active monitors 304 or between the activemonitor membership can be arbitrated at the actuator itself 106, by themiddleware 204, or by a distributed device remote from, but incommunication with, the middleware 204. Because some output of the QMinstances 306 may not be verified, and thus cannot be trusted andbecause some instances of active monitors 304 may be susceptible toanother device or process masquerading as a valid active monitor (e.g.,spoofing), some active monitors and QM instances authenticate themselveswith the actuators 106, middleware 204, or remote distributed arbiterdevices before fulfilling their intended purpose. In theseimplementations, when an active monitor or QM is not authenticated,their output is disregarded.

FIG. 4 shows an embedded system implemented with active monitors andarbitrators provided through the middleware 204 implemented throughlibraries 402 & 404. The shared computer resources, data, and middlewarethat are provided on demand through the computing network shown in FIGS.2 and 3 are provided through libraries (referred to as a server library402 in FIG. 4) linked to the computation engines and libraries (referredto as a client library 404 in FIG. 4) linked to the sensors 104 andactuators 106 as shown in FIG. 4. The libraries 402 & 404 provide anapplication program interface (API) between the respective applicationsoftware executed by the replicated and diversified computation engines202 and actuators 106 and the loosely-coupled locked-step architecturemiddleware services that provide a distributed execution model for theembedded systems and gives the appearance of a synchronous executionthat is compliant with safety integrity levels or standards. In FIG. 4,the server APIs permit one or more computation engines 202 to join oneor more groups and receive and respond to messages. Groups do not haveto be defined in advance, the first computation engine instance joininga group effectively creates that group. Further, memberships can changemaking group membership dynamic. While a computation engine instancecan, for load-sharing purposes, request details of the number of membersand its sequence number within a group, the computation engine orengines need not to be aware of other instances or members in its groupor groups.

On the sensors and actuators side, the client-side APIs do not belong orserve a group. The client-side APIs permit the sensors and actuators tosend requests to the replicated and diversified computation engine groupmembers with a particular ordering, and to receive back one, some, orall of the responses from the group members.

FIG. 4 further illustrates the connectivity between the variousinstances of the replicated or diversified computation engines 202. In adevice or application where safety is a concern, this is implementedthrough a black communication channel. In an alternative device wheresafety is a concern connectivity occurs through a trusted or a sharedsecure electronic memory when the processes are executed on the sameprocessor. In some implementations, the loosely-coupled locked-steparchitecture makes few demands on the guarantees offered by thecommunications channel and a data distribution service (DDS) may serveas an intermediate layer. At the physical layer, such as in a vehicle,for example, this connectivity might be provided through the CAN bus, avirtual network or bus, or an Ethernet.

To address severe failures in connectivity that might occur in thegroups of replicated or diversified computation engines and those thatinclude active monitors, a DSS or design-safe process is practiced. Whenfailure is detected (a detection that can be made by the middleware 202or 402 & 404), such as when a node fails or a timeout occurs, themiddleware 202 or 402 & 404 shuts down only the affected hardware orcomputation engines to prevent output divergence.

FIG. 6 is an overview of a process that detects hardware and softwarefaults in an embedded system. The embedded system may comprise avehicle, medical device, food or beverage dispenser or vending machine(e.g., soda machine), a control room (e.g., a nuclear power stationcontrol room) or other systems, for example, including any other systemthat relates to health or safety. When the embedded system is on-lineand in a running state, sensors 104 detect or measure the operatingstate of the system it is integrated within at 602. In some instances,the sensors 104 measure or detect something by converting non-electricalenergy into electrical energy. The output of the sensors 104 istransmitted to a group of replicated or diversified computation engines202 or 308 and replicated or diversified active monitors 304 or safetybags that operate in virtual or group synchrony at 604 and 606,respectively. Virtual or group synchrony comprises a dynamic process ofgroups that are self-managed (computation engines and active monitorscan join and leave their respective groups at will), delivers data atthe same data rates as network multicasts, and communicates bypiggybacking extra information on regular messages that carry updates.At 608, the loosely-coupled locked-step architecture's middleware 204 or402 & 404 synchronizes the communication between the operatingcomputation engine instances 202 or 308 and active monitor instances 304and compares the reconciled limits or ranges generated by the activemonitor instances 404 to the reconciled output generated by thecomputation engine instances 202 or 308. The middleware 204 or 402 & 404compares the outputs and flags occurrence where the output does not fallwithin the predefined range. Both the outputs and associated flags aretransmitted directly to the actuators 106, transmitted to anintermediate arbiter remote from the middleware 204 or 402 & 404 andactuators 106 that reconciles the differences and transmit a controlsignals to the actuators 106 in response to the reconciliation, or isnot transmitted. When not transmitted the outputs and associated flagsare reconciled by the middleware itself 204 or 402 & 404 via an internalarbiter that transmits control signals to the actuators at 612.

In some processes, the arbiter commands and actuator applies a DSS whena severe conflict, availability, or reliability issue arises. Inalternative processes, the arbiter modifies or alters the output of thecomputational engine instances so that it is compliant with themonitoring standard generated by the active monitor instances, and inresponse, transmits a control signal to one or more actuators thatreflects the signal's modification.

The loosely-coupled locked-step architecture's middleware 204 or 402 &404 may comprise a processor or a portion of a program retained in amemory that serves as a bridge between the client-side sensors andactuators and the server side replicated or diversified computationengines and optional replicated or diversified active monitors. Themiddleware 204 or 402 & 404 provides fault-tolerance, consistency,concurrency, and reduces the complexity of programming by providingengine synchronization, casual and concurrent asynchronous messaging,message ordering, and state transfers in the embedded system. In someimplementations, the middleware 204 or 402 & 404 dynamically enablesmembers in the computational engine groups enabling one or more QMengines under certain events (such as two instances of QM when a vehicleis operating on a highway) and fewer or more QM engines under otherevents (such as three instances of QMs when a vehicle is operating inthe city). An event generally refers to an action or occurrence detectedby the middleware 204 or 402 & 404 through one or more sensors 104 orother inputs. An engine generally comprises a processor or a program orportion of a program executed by the processor that manages andmanipulates data and performs one or more specific tasks.

The middleware 204 or 402 & 404 also overcomes the failings ofconventional technologies that do not adapt to synchronizing embeddedsystems. It is difficult to know if a message reaches all computationengines with conventional technologies and if the disclosed middleware204 or 402 & 404 is not implemented, it is not clear how to correctfailures when a message is not delivered. Computation engines in amembership group do not always change instantaneously, making it isdifficult to track the number of messages sent to computational enginemembers and the number of messages they received if the disclosedmiddleware 204 or 402 & 404 is not used. And should a node in amembership group fail, especially in the middle of a transmissioncausing some nodes to receive a message and others not, an inconsistentstate may result if not detected and corrected as done by the disclosedmiddleware 204 or 402 & 404 creating a safety issue in the embeddedsystem (e.g., the vehicle). A node generally refers to any computationengine coupled through a communication medium or link.

In some architectures, the elements, systems, processes, engines,algorithms and descriptions described herein may be encoded in anon-transitory storage medium, a computer-readable medium, or maycomprise logic stored in a memory that may be accessible through aninterface. Some signal-bearing storage medium or computer-readablemedium comprise a memory that is unitary or separate (e.g., local orremote) from the vehicle. If the descriptions are performed by software,the software may reside in a memory resident to or interfaced to the oneor more processors or multicore processors.

The systems and methods described are self-adaptive and extensive andevolve with the standards referenced above including ISO 26262 and IEC61508, for example, as the standards evolve or overtime. As such,references to those standards include the current and future versions ofthose standards, any related standards of the current and futureversions, and any superseding standards.

The memory or storage disclosed may retain an ordered listing ofexecutable instructions for implementing the functions described above.The machine-readable medium may selectively be, but not limited to, anelectronic, a magnetic, an optical, an electromagnetic, an infrared, ora semiconductor medium. A non-exhaustive list of examples of amachine-readable medium includes: a portable magnetic or optical disk, avolatile memory, such as a Random Access Memory (RAM), a Read-OnlyMemory (ROM), an Erasable Programmable Read-Only Memory (EPROM or Flashmemory), or a database management system. When messages, actuators,computation engines, QMs, active monitors, safety bags, and/or otherdevice functions or steps are said to be “responsive to” or occur “inresponse to” a function or message, the messages, actuators, computationengines, QMs, active monitors, safety bags, and/or other devicefunctions or steps necessarily occur as a result of the message orfunction. It is not sufficient that a function or act merely follow oroccur subsequent to another, causal ordering is necessary.

The disclosed loosely-coupled locked-step architecture for embeddedsystems makes use of replication and diversification through virtualsynchrony. The architecture is effective in detecting and mediatinghardware and software errors. When a software instance or hardwarefails, for example, because of an error such as a random error, thedisclosed architecture ensures that the failing system continues tooperate. In some instances, the failing system may operate in a degradedstate or a program defined DSS. When detected, the architecture'smiddleware automatically restarts the hardware or restarts all or aportion of the system's code.

The disclosed architecture separates two aspects of software design: thetechnical and algorithmic skill required to write or implement softwarethat fulfills a particular purpose; and the statistical skill requiredto determine the level and timing of replication and diversity. Thedisclosed architecture allows the level of resiliency required for aparticular subsystem to be programmed or actuated in response tosoftware's own control and to be modified or actuated dynamically duringthe embedded system's operation in the operating environment or state ofthe embedded system. In a vehicle application the operating environmentor state may comprise a cruising state, an urban driving state, a ruraldriving state, a parking state, a high or a low traffic congestionstate, or any other vehicle operating state or any traffic conditionstate or any combination of any of the above environments or states.And, the resiliency level may establish the number of replicas activatedin response to an event and their activation times or periods, thenumber of responses required before a response is accepted and actedupon, and the number of diverse implementations required. A vehicle maycomprise, without limitation, a car, bus, truck, tractor, motorcycle,bicycle, tricycle, quadricycle, or other cycle, ship, submarine,hoverboard, boat or other watercraft, helicopter, drone, airplane orother aircraft, train, tram or other railed vehicle, spaceplane or otherspacecraft, and any other type of vehicle whether currently existing orafter-arising this disclosure. In other words, it comprises a device orstructure for transporting persons or things.

The disclosed architecture also supports diverse computation engines andactive monitors or safety bags which enables design to be partitioneddynamically and on-line with ASILs including the decomposition levelscalled out in the ISO 26262 standard, for example.

The underlying replication and diversification of the disclosedarchitecture can verify new and legacy software efficiently at the startor during the software's execution to any of the functional safetylevels of a standard such as anyone of the ASIL standards described inthe ISO 26262 standard without software being compliant from the start.The disclosed architecture and middleware may reduce the proofs asoftware program requires for certification by certification authoritiesand ensures operational integrity levels. Further, the disclosedarchitecture is not limited to vehicles as it is used in other fields,including those areas in which reliable and dependable performance isprized, such as in medical devices, for example, that may dispensedrugs, assist in microscopic surgery, etc., control rooms (e.g., nuclearpower station control rooms, etc.), and other fields and applications.The disclosed architecture can be used in any system or process that canbe embedded in another system or process.

Other systems, methods, features and advantages will be, or will become,apparent to one with skill in the art upon examination of the figuresand detailed description. It is intended that all such additionalsystems, methods, features and advantages be included within thisdescription, be within the scope of the disclosure, and be protected bythe following claims.

What is claimed is:
 1. An embedded system, comprising: a plurality ofsensors that detect or measure a state; a plurality of actuators thatactivate or control another mechanism; a plurality of replicatedcomputation engines in communication with the plurality of sensors andthe plurality of actuators that perform a specific task, wherein theplurality of replicated computation engines are replicated instances ofa single computation engine and wherein the plurality of replicatedcomputation engines are grouped into one or more groups such that, foreach group, each member of the group starts in a same processing logicstate and processes same events in the same order; and a middlewareexecuted by a processor that actuates selected computation engines ofthe plurality of replicated computation engines and arbitrates betweenoutputs of the selected computation engines, wherein the middlewareintercepts the output of the plurality of sensors and transmits theoutput to each replicated computation engine of a group in a definedorder.
 2. The system of claim 1 where the arbitration executed by themiddleware places an embedded system in a design safe state.
 3. Thesystem of claim 1 where the middleware is programmed to detect ahardware error and isolate the hardware error.
 4. The system of claim 1where the plurality of replicated computation engines are physicallydistinct and executed by different processors but appear to theplurality of actuators as a single unit.
 5. The system of claim 1 wherethe replicated computation engines that belong to a group aresynchronized.
 6. The system of claim 1 where the actuators areprogrammed to request only a portion of a selected output generated bythe plurality of replicated computation engines.
 7. The system of claim1 further comprising a plurality of active monitors in communicationwith the middleware.
 8. The system of claim 7 where the plurality ofactive monitors receives the same sensor output as the plurality ofreplicated computation engines.
 9. The system of claim 8 where theplurality of active monitors calculates the same output as the pluralityof replicated computation engines but process a different combination ofa sensor output.
 10. The system of claim 7 where the active monitors arecompliant with a safety standard such that a number of the plurality ofreplicated computation engines that are non-compliant with the safetystandard become compliant by a monitoring executed by the plurality ofactive monitors.
 11. The system of claim 7 where the middlewarearbitrates between the output generated by the plurality of replicatedcomputation engines and the output of the plurality of active monitors.12. The system of claim 7 where the plurality of replicated computationengines and the plurality of active monitors operate in a virtualsynchrony model, respectively.
 13. An embedded system, comprising: aplurality of sensors that detect or measure a state; a plurality ofactuators that activate or control another mechanism; a plurality ofcomputation engines in communication with the plurality of sensors andthe plurality of actuators, the plurality of computation enginesoperating in group synchrony wherein the plurality of replicatedcomputation engines are replicated instances of a single computationengine and wherein the plurality of replicated computation engines aregrouped into one or more groups such that, for each group, each memberof the group starts in a same processing logic state and processes sameevents in the same order; a plurality of active monitors that monitorthe plurality of computation engines to an automotive integrity level,the plurality of active monitors operating in group synchrony; and amiddleware executed by a processor that synchronizes the communicationbetween the plurality of computation engines and the plurality of activemonitors, respectively, wherein the middleware intercepts the output ofthe plurality of sensors and transmits the output to each replicatedcomputation engine of a group in a defined order; where the plurality ofactuators arbitrates between the output generated by the plurality ofcomputation engines operating and output generated by the plurality ofactive monitors.
 14. The system of claim 13 where the plurality ofactive monitors transforms computation engines non-compliant with asafety standard into computation engines compliant with safety standard.15. The system of claim 13 where the middleware is programmed to detecta hardware error and isolate the hardware error when the hardware erroris detected.
 16. A non-transitory computer readable medium storing aprogram that detects hardware and software errors in an embedded systemof a vehicle, comprising: computer program code that detects or measuresan operating state of the vehicle; computer program code that activatesor controls another mechanism within the vehicle; computer program codethat causes a plurality of computation engines to operate in groupsynchrony within the vehicle, wherein the plurality of replicatedcomputation engines are replicated instances of a single computationengine and wherein the plurality of replicated computation engines aregrouped into one or more groups such that, for each group, each memberof the group starts in a same processing logic state and processes sameevents in the same order; computer program code that causes a pluralityof active monitors that monitor the plurality of computation engines toan automotive integrity level to operate in group synchrony within thevehicle; computer program code that synchronizes the communicationbetween and from the plurality of computation engines and the pluralityof active monitors, respectively wherein the middleware intercepts theoutput of the plurality of sensors and transmits the output to eachreplicated computation engine of a group in a defined order; andcomputer program code that arbitrates between output generated by theplurality of computation engines and output generated by the pluralityof active monitors.
 17. The non-transitory computer readable medium ofclaim 16 where the plurality of computation engines comprises aplurality of computation engines non-compliant with a safety standardand further comprising means rendering the embedded system including theplurality of non-compliant computation engines compliant with safetystandard without modifying the plurality of non-compliant computationengines.
 18. A process that detects hardware and software failuresthrough a loosely-coupled locked-step architecture, comprising:detecting or measuring an operating state; operating a plurality ofcomputation engines in group synchrony, wherein the plurality ofreplicated computation engines are replicated instances of a singlecomputation engine and wherein the plurality of replicated computationengines are grouped into one or more groups such that, for each group,each member of the group starts in a same processing logic state andprocesses same events in the same order; operating a plurality of activemonitors that monitor the plurality of computation engines to anintegrity level to operate in group synchrony; synchronizing thecommunication between and from the plurality of computation engines andthe plurality of active monitors, respectively, through middleware,wherein the middleware intercepts the output of the plurality of sensorsand transmits the output to each replicated computation engine of agroup in a defined order; and arbitrating between output generated bythe plurality of computation engines and output generated by theplurality of active monitors.
 19. The process of claim 18 furthercomprising actuating a mechanical device in response to the act ofarbitrating.
 20. A vehicle, comprising: a plurality of sensors thatdetect or measure a state of the vehicle; a plurality of actuators thatactivate or control another mechanism in the vehicle; a plurality ofcomputation engines in communication with the plurality of sensors andthe plurality of actuators, the plurality of computation enginesoperating in group synchrony wherein the plurality of replicatedcomputation engines are replicated instances of a single computationengine and wherein the plurality of replicated computation engines aregrouped into one or more groups such that, for each group, each memberof the group starts in a same processing logic state and processes sameevents in the same order; a plurality of active monitors that monitorthe plurality of computation engines to an automotive integrity level,the plurality of active monitors operating in group synchrony; and amiddleware executed by a processor that synchronizes the communicationbetween the plurality of computation engines and the plurality of activemonitors, respectively, wherein the middleware intercepts the output ofthe plurality of sensors and transmits the output to each replicatedcomputation engine of a group in a defined order; where the plurality ofactuators arbitrates between the output generated by the plurality ofcomputation engines operating and output generated by the plurality ofactive monitors.